Summary

• Fixes a permanent false-positive drift report in apply-repo-settings's ruleset sync, traced from nsheaps/.github#103 / #45 (an investigation into whether the automation app was actually configured as a require-pr bypass actor on nsheaps/greasemonkey-scripts).
• Conclusion of that investigation: there was no real bypass_actors gap — the automation app was already correctly configured and had already successfully pushed directly to greasemonkey-scripts main under this exact ruleset. The apparent "still needs update" signal was a false positive in this action's drift-detection logic.

Root cause

apply_rulesets()'s current-vs-desired comparison does:

current_norm="$(gh api ".../rulesets/${id}" --jq '{name, target, enforcement, conditions, rules, bypass_actors}' | jq -S '.')"
desired_norm="$(echo "$body" | jq -S '{name, target, enforcement, conditions, rules, bypass_actors}')"

jq -S sorts object keys, not array element order. GitHub doesn't guarantee bypass_actors[] comes back in the same order settings.yml declares them, so when the live and desired sets are identical but differently ordered, the plain string comparison reports drift forever.

Confirmed via workflow run 30285386587 (dry-run dispatch of apply-repo-settings.yaml on nsheaps/greasemonkey-scripts): the diff for require-pr (and identically for require-1-review, require-codeowner-review) showed the same two bypass actors present on both sides, just at swapped array positions — not a missing actor.

Fix

Sort bypass_actors by a stable key (actor_type, actor_id) on both current_norm and desired_norm before the jq -S comparison, so ordering differences no longer register as drift.

Test plan

• bash -n — syntax check passes.
• shellcheck .github/actions/apply-repo-settings/action.sh — clean, no warnings.
• Extracted the exact ruleset_filter jq expression and ran it standalone against synthetic JSON reproducing the reported scenario (two bypass actors present on both sides, swapped order) — confirms current_norm == desired_norm after the fix (previously would differ).
• Ran the same filter against a genuine-gap case (one side missing an actor entirely) — confirms real drift is still correctly detected, i.e. the fix doesn't mask actual config gaps.
• Not yet exercised end-to-end against a live repo from this branch (this action is only invoked via uses: nsheaps/github-actions/.../apply-repo-settings@main by consumers, so a live check requires either this landing on main or a consumer temporarily pointing at this branch — first live exercise will be the next real apply-repo-settings dry-run/apply run once merged).

Known separate issue (not fixed here)

The same dry-run log also showed allowed_merge_methods/required_reviewers: [] flip-flopping between current and desired — GitHub backfills some rule parameters with defaults that settings.yml never explicitly sets, causing a second, unrelated false-positive. Deliberately left out of this change to avoid guessing at GitHub's per-rule-type default-fill behavior without more research; flagged as a follow-up.

🤖 Generated with Claude Code